Продолжаем рассказывать технические подробности о работе продукта StarWind Virtual SAN, позволяющего создавать программные и программно-аппаратные отказоустойчивые кластеры iSCSI для виртуальных сред. Сегодня мы поговорим о расширенных настройках протокола iSCSI на стороне StarWind и на стороне VMware ESXi, чтобы обеспечить непрерывное функционирование приложений в виртуальных машинах при обрыве соединений.
Стек работы с хранилищами VMware ESXi настроен таким образом, чтобы адекватно реагировать на кратковременную потерю сигнала в канале iSCSI, которая может возникнуть по разным причинам (кто-то перекоммутировал соединение, дрогнул порт и т.п.). По умолчанию расширенные настройки iSCSI выставлены так, чтобы переживать кратковременные сбои в рамках одного пути в интервале 25-35 секунд. В это время I/O-запросы будут копиться в очереди, а потом, либо произойдет продолжение передачи при восстановлении текущего соединения, либо хост переключится на резервный путь (failover) текущего или резервного адаптера.
В то время, как такое поведение не является критичным для большинства приложений, иногда есть специфические требования, которые надо выполнять для отдельных систем. Например, если речь идет о системе видеонаблюдения, то там задержка в полминуты является неприемлемой, и ее надо обрабатывать быстрее.
Для этого, если вы используете хранилища StarWind Virtual SAN, есть специальные настройки реагирования на подобные ситуации.
Итак, для начала вам нужно остановить службы StarWind Virtual SAN:
В консоли StarWind Management Console проверить, что все устройства StarWind HA находятся в статусе "Synchronized" на всех серверах
Проверить, что все датасторы имеют активные задублированные пути для всех серверов StarWind, а политика доступа по нескольким путям (MPIO) установлена в Round Robin
На StarWind VSAN для Windows нужно выполнить команду для остановки служб StarWind: net stop starwindservice
На виртуальном модуле StarWind VSA нужно выполнить такую команду: systemctl stop StarWindVSA
Далее открываем конфигурационный файл:
На StarWind VSAN для Windows: C:\Program Files\StarWind Software\StarWind\StarWind.cfg
На виртуальном модуле StarWind VSA: nano /opt/StarWind/StarWindVSA/drive_c/StarWind/StarWind.cfg
Далее там находим параметр iScsiPingCmdSendCmdTimeoutInSec и выставляем его значение, например в "1" (одна секунда).
Ну и, наконец, надо запустить службы StarWind VSAN:
На StarWind VSAN для Windows: net start starwindservice
На виртуальном модуле StarWind VSA: systemctl start StarWindVSA
Теперь нужно добраться до расширенных настроек iSCSI инициатора VMware ESXi. Открываем Advanced Options для адаптера в разделе Storage Adapters нужного нам инициатора:
И смотрим, какие настройки там выставлены:
Нас интересует:
RecoveryTimeout - это как раз время, через которое активный путь помечается как "мертвый" (переводится в DEAD_STATE), когда по нему больше не приходит команд ввода-вывода.
NoopInterval - это интервал, с которым происходит пассивное тестирование неактивных путей на предмет того, живы ли они.
NoopTimeout - это время, через которое происходит пометка неактивного пути как DEAD, если по нему не получено ответа.
Эти настройки по умолчанию установлены в оптимальные с точки зрения вероятности отказа/потерь значения. Меняйте их только, если у вас есть особые требования приложений по непрерывной доступности хранилищ, и вы знаете, какое поведение системы хотите получить. Уменьшение таймаутов, очевидно, ведет к загрузке сети пингами каналов iSCSI и дополнительной нагрузке на устройства.
Напомним, что это средство предназначено для администраторов, сотрудников технической поддержки и системных инженеров, которые ищут причины проблем различного характера в виртуальной инфраструктуре и решают их на базе аналитики лог-файлов.
Давайте посмотрим на новые возможности январского обновления Log Insight Cloud:
1. Разделы Index и Non-Index Log Partitions
Теперь в продукте появилась поддержка безындексных разделов (non-index Log Partitions), что позволяет увеличить масштабируемость решения для публичных многооблачных сред, где происходит мониторинг огромного количества объектов (AWS, Microsoft Azure, Google Cloud Platform), а также облаков на базе VMware Cloud (VMware on AWS, Azure VMware Solutions, Google Cloud VMware Solutions, Oracle Cloud VMware Solutions). Также это доступно и для онпремизной инфраструктуры на базе VMware SDDC (software-defined-datacenter).
Хранение, индексирование и управление данными лог-файлов может стать очень затратным с точки зрения ресурсов, так как может вовлекать обработку миллионов записей в минуту. При этом разные данные должны обрабатываться в соответствии с различными регулирующими процедурами. Log Partitions предоставляют гибкий функционал про обработке логов при соблюдении специфических требований.
Если вам требуется долговременное хранение данных логов, доступ к которым происходит нечасто, то неиндексируемые разделы - это оптимальный выбор.
Также можно изменить приоритет обработки логов на разных разделах в соответствии с требованиями регулирующих процедур. Ну а если вы понимаете, что доступ к данным с неиндексируемого раздела происходит часто, то можно сменить тип раздела на индексируемый.
Вот так выглядит матрица функциональности индексируемых и неиндексируемых разделов:
2. Визуализация потребления хранилищ
Настройка логирования - это всегда компромисс между объемом собираемых и анализируемых данных и трат на их хранение. С помощью функций Ingestion and Storage Summary в реальном времени можно наблюдать за тем, как разделы заполняются логами и с какой скоростью, в соответствии с опциями, которые вы задали для них. На дэшборде видны наиболее потребляющие дисковое пространство разделы:
3. Функции Cloud Native Collector
Cloud Native Collector - это Docker-контейнер, который можно установить в любом облаке. Он предоставляет функции агрегации логов и управления конфигурациями логирования в части их форвардинга в систему vRealize Log Insight Cloud. Это позволяет собирать логи откуда угодно, без ограничений по хранимым емкостям.
Более подробно о новом релизе VMware vRealize Log Insight Cloud от января 2022 года можно узнать в Release Notes.
На прошедшей в конце прошлого года конференции VMworld 2021 компания VMware объявила о выпуске новой версии продукта vRealize Operations 8.6, который также включал в себя релиз облачной версии Operations Cloud. Напомним, что vROPs - это решение для комплексного управления и мониторинга виртуальной инфраструктуры в различных аспектах.
На днях компания VMware сделала обновление облачной версии vRealize Operations Cloud, давайте посмотрим, что там появилось нового:
1. Выбор региона размещения сервисов vROPs Cloud
Теперь пользователь может выбрать один из восьми географических регионов (см. карту VMware Global Infrastructure Availability Map), где будут физически размещены сервисы vRealize Operations Cloud.
2. Покупка решения прямо из интерфейса
Если пользователь начал с пробной версии продукта на 30 дней, то в любой момент теперь у него есть возможность купить подписку:
Можно купить либо отдельные подписки на облачные продукты Operations, Automation, Log Insight и Network Insight, либо взять пакет подписок в рамках предложения vRealize Cloud Universal:
3. Удаление дочерних объектов в соответствии с политикой
Теперь политика Deleted Objects retention применяется и ко всем дочерним объектам, которые зависят от Adapter instance. Это позволяет не оставлять не привязанные ни к чему дочерние экземпляры адаптеров при удалении родительского:
Также можно при удалении инстанса поставить галочку "Delete related objects", чтобы удалить все объекты, исторические данные, назначения пользователей и прочие сопутствующие вещи.
Больше подробностей об обновлении VMware vRealize Operations Cloud приведено в Release Notes. Пробную версию этого решения на 30 дней можно запросить тут. Также можете поработать с этим продуктом в виртуальной лаборатории по этой ссылке.
Компания VMware в конце января объявила о том, что ее сервис Skyline доступен через партнерскую сеть облачных сервис-провайдеров (Cloud Providers, они же участники программы VCPP), которые предоставляют свои услуги, используя платформу Cloud Partner Navigator (CPN). Напомним, что это решение предназначено для проактивного получения рекомендаций по технической поддержке продуктов линейки VMware vSphere, включая vSAN. В частности, с помощью VMware Skyline пользователи и инженеры технической поддержки VMware (Technical Support Engineers, TSEs) могут делать заключения о правильности работы виртуальной инфраструктуры и вырабатывать основные рекомендации по ее улучшению.
С помощью Skyline Advisor пользователи могут получать проактивную аналитику для своей виртуальной инфраструктуры в целях идентификации текущих и будущих проблем. Он поддерживает не только продукты vSphere, vSAN, NSX, vROps и Horizon, но и среды Cloud Foundation и Dell EMC VxRail.
Все партенры, имеющие доступ к VMware Partner Connect с действующим соглашением VMware Cloud Provider Program agreement, могут получить доступ к поддержке уровня Production. А начиная с 27 января, у них уже есть доступ к сервисам VMware Skyline.
Для сервис-провайдеров тут будет 2 больших плюса:
Получение инструмента, который позволяет обозначать проблемы пользователей еще до их появления и проактивно действовать в этом направлении.
Быстро и удобно взаимодействовать с поддержкой VMware через единый портал для ускорения решения проблем пользователей.
На данный момент сервисы Skyline доступны для следующих продуктов:
VMware vSphere
VMware NSX
VMware vSAN
VMware vRealize Operations
VMware vRealize Automation
VMware Cloud Foundation.
Также сервис распознает Skyline инфраструктуру VxRail и инсталляции типа VMware Validated Design.
Если вы являетесь сервис-провайдером VCPP и уже имеете доступ к Cloud Partner Navigator, то сервис доступен в разделе "Services Available for Provisioning".
Как знают многие администраторы, еще в прошлом году в ESXi 7 Update 2 компания VMware стала убирать различные настройки из основного конфигурационного файла esx.conf. Кстати, и не только оттуда. Например, раньше глобальные настройки FDM (он же HA - High Availability) хранились в файле /etc/opt/vmwware/fdm/fdm.cfg. Теперь их там тоже нет - они переехали во внутреннее хранилище ConfigStore, работать с которым нужно с помощью утилиты командной строки configstorecli.
То же самое произошло и с NTP - теперь настройки времени, хранящиеся в /etc/ntp.conf (для NTP) и /etc/ptp.conf (для PTP), недоступны для редактирования через файлы конфигураций. Кстати, если вы не знаете, чем NTP отличается от PTP, у нас есть отличная статья на эту тему (а вот тут - о поддержке PTP в vSphere 7 Update 2).
Более того, теперь все файлы каталога /etc помечены как только для чтения и не сохраняют своих изменений при перезагрузке!
Так что работать с большинством настроек теперь нужно через ConfigStore. В частности, для NTP и PTP есть 2 основных команды, которые взаимодействуют с ConfigStore для конфигурации времени:
Получение настроек времени
# esxcli system ntp get
# esxcli system ptp get
Установка настроек времени
# esxcli system ntp set
# esxcli system ptp set
Если вы хотите узнать список всех конфигурационных файлов, которыми теперь заведует ConfigStore, можно выполнить следующую команду в консоли ESXi:
Как многие из вас знают, в ноябре прошлого года компания VMware отозвала обновление платформы vSphere 7 Update 3 из-за критических ошибок. Это были проблемы с выпадением в PSOD, трудности при апгрейде с прошлых версий, неполадки в плане стабильности vSphere HA и другое.
В конце декабря мы напомнили о том, что проблема существует уже месяц, а VMware все никак не может решить ее. Основная информация о возникшей ситуации с последним пакетом обновлений публиковалась в KB 86398. Там же можно узнать, что вся линейка Update 3/3a/3b была отозвана из-за критических проблем, описанных в KB 86287 и KB 86281.
Теперь VMware объявила о выпуске окончательной версии VMware vSphere 7 Update 3c, где все должно работать как надо (однако бежать обновляться прямо сейчас мы бы не рекомендовали:)
Также сообщается, что в новом релизе решены все проблемы с безопасностью, касающиеся уязвимости Log4j, которая затронула большое количество систем. Эта уязвимость позволяла злоумышленнику, который имел доступ к отсылке логов (самих сообщений или к настройке их параметров), исполнять код, полученный с LDAP-серверов, когда настройка message lookup substitution включена.
Наконец-то были обновлены основные компоненты продукта, ESXi и vCenter, а также опубликован список известных проблем и их обхода:
О новых возможностях основного vSphere 7 Update 3 вы можете почитать у нас тут, их список не изменился. Скачать все компоненты платформы, включая ESXi 7 Update 3c и vCenter Server 7 Update 3c, вы можете по этой ссылке.
В Enteprise-инфраструктуре перед администраторами контейнеров и серверов виртуализации встают следующие задачи:
Удовлетворение все растущего спроса разработчиков на размещение контейнеров приложений в кластерах.
Уход от механизма тикетов на выполнение задач DevOps путем предоставления разработчикам средств самообслуживания и API-механизмов для решения собственных задач.
Предотвращение ситуации, когда все будет завязано на одного вендора (например, только на его API).
Соответствие регуляторным требованиям, которые часто требуют размещения приложений и данных только в онпремизной инфраструктуре.
Поддержка железа для кластеров Kubernetes, а также виртуального датацентра на базе VMware vSphere.
Все эти важные аспекты рассматриваются в данной книге. Полезна она будет как администраторам в целях исполнения своих прямых обязанностей, так и разработчикам, которые хотят расширить кругозор и составить представление о современных подходах к интеграции технологий контейнеризации приложений и серверной виртуализации.
Скачать книгу "Production Kubernetes - Building Successful Application Platforms" можно бесплатно по этой ссылке.
В прошлом году на VMworld 2021 компания VMware представила обновление продукта Workspace ONE Intelligence, который предназначен для для анализа поведения пользователей и устройств и выдачи рекомендации администраторам ИТ-инфраструктуры по применению тех или иных действий. На вход этого движка подаются данные об использовании устройств, приложений и данных пользователей, затем они агрегируются, анализируются, а потом для администраторов генерируются некоторые рекомендации и правила, которые можно применить для повышения эффективности инфраструктуры виртуальных ПК и приложений.
Тогда мы рассказали о новых возможностях этого продукта, а сегодня вкратце расскажем о том, какие основные его функции позволяют повысить безопасность пользовательской среды в рамках концепции Zero Trust Security, то есть когда никакие из систем предприятия по умолчанию не считаются 100% защищенными.
1. Мониторинг и отслеживание аномалий
Workspace ONE Intelligence позволяет пользователям отслеживать изменения метрик в их окружениях, касающихся аномалий в производительности и безопасности, а также проактивно корректировать их с помощью созданных сценариев автоматизации. На картинке ниже представлена временная картинка с трендами рисков, где администратор может погрузиться в отдельную систему для их детального понимания:
2. Доверенная экосистема (Trust Network)
В дополнение к данным окружения платформы Workspace ONE (включая Workspace ONE UEM и Workspace ONE Access), данные могут быть дополнены средствами внешних систем, входящих в доверенную экосистему Trust Network.
Например, вы можете подключить систему VMware Carbon Black, которая также может встроиться в окружение Workspace ONE. Например, вот два виджета, которые отображают Threat Count и Threat Type от Carbon Black в консоли Workspace ONE Intelligence:
3. Автоматизации для работы с данными об угрозах
Вы можете настроить различные автоматизации для действий в ситуации наступления определенных угроз. К примеру, если решение Carbon Black обнаружило какое вредоносное ПО в системе, например, ransomware, то система может быть помещена на карантин, а в Slack будет отправлено сообщение, оповещающее о проблеме. Затем будет создан тикет в ServiceNow, а Workspace ONE UEM протэгирует опасный объект и поместит его на карантин:
4. Аналитика рисков устройств и пользователей
Для дальнейших исследований аномалий в рамках экосистемы инфраструктуры виртуализации система может сделать скоринг рисков для устройств и пользователей на базе датасета, имеющегося в Workspace ONE. Вот так это выглядит:
Более подробно об этих всех возможностях можно почитать в документации.
Весной 2020 года компания VMware объявила об интеграции своей платформы для виртуализации и доставки настольных ПК предприятия Horizon с решениями компании ControlUp, которая является технологическим партнером VMware.
В ноябрьском обновлении VMware Horizon 2111, о котором мы писали вот тут, эта интеграция уже реализована. Суть данных интеграций - дать администраторам набор инструментов для отладки подключений и производительности виртуальных ПК пользователей, который все чаще стали работать из дома, а значит в очень неоднородной среде с точки зрения скорости и стабильности соединения.
Первый продукт, который поддерживает новый релиз - это решение Scoutbees. Оно позволяет мониторить доступность сетевых ресурсов (десктопы, приложения, компоненты VMware UAG и DNS и прочее) и оповещать администраторов о проблемах, с которыми сталкиваются пользователи. Путем анализа проблем (они могут и не подтвердиться на стороне клиента) - администраторы предпринимают определенные действия по улучшению соединений.
Scoutbees осуществляет синтетический мониторинг, то есть посылает запросы к удаленному ресурсу и получает не только ответ, но и метрики key performance indicators (KPI), которые могут использоваться для целей прогнозирования и анализа подозрительных активностей. Для анализа инфраструктуры виртуальных ПК вы можете подключить мониторинг компонентов VMware Unified Access Gateway (UAG) и Horizon Connection Server. Также решение может проактивно тестировать доступность веб-приложений, сетевых служб, DNS-серверов, файловых шар, принтеров и других ресурсов.
Scoutbees - это облачный SaaS-продукт, который можно начать использовать прямо из браузера, без необходимости развертывания в своей инфраструктуре. Есть также и онпремизная его версия.
Вторая интеграция - это возможность использования решения Remote DX для мониторинга компьютеров удаленных пользователей. Это средство позволяет удаленно собрать информацию о скорости и качестве Wi-Fi соединения, а также производительности подключения пользователя к интернету. Вследствие этого администраторы могут делать скоринг пользователей по этому параметру и решать возникающие проблемы пользователей. Вот, например, у пользователя задержка (latency) составляет 219 миллисекунд между его устройством точкой доступа Wi-Fi. А между Horizon Client и его десктопом Horizon задержка равна 362 миллисекундам.
С использованием Remote DX администратор видит, что у пользователя относительно сильный сигнал Wi-Fi на уровне 81% и round-trip time (RTT), которое для гугла составляет 244 миллисекунды. А вот от роутера до гугла пользователь получает задержку 25 мс - это значит проблема в связи между устройством пользователя и его роутером.
По умолчанию решение Remote DX отображает только основные метрики, но собирает оно все, и их можно вывести для отображения в таблице:
Также можно использовать ControlUp Real-Time Console для вывода информации информации в колонках в соответствии с заранее сделанными пресетами:
Самая главная метрика здесь - это Client Device Score, которая дает администратору понять, все ли в порядке у пользователя с интернетом и доступом к удаленному десктопу в целом. Также есть и другие колонки, которые помогут вам понять, в чем дело, если у пользователя есть проблемы:
Более подробно об интеграции VMware Horizon и Remote DX рассказано вот в этой статье.
Некоторые из вас, вероятно, знают такой сайт virten.net, где в свое время публиковалось много интересных технических статей об инфраструктуре VMware. Автор этого ресурса делает много интересных вещей, например, средство PowerShell OVF Helper.
OVF Helper - это репозиторий шаблонов для развертывания ВМ из виртуальных модулей (Virtual Appliances) в формате OVF, которые основаны на рабочем процессе развертывания в мастере создания машин vSphere Client. Через OVF Helper вы таким же образом соединяетесь с vCenter Server, заполняете нужные переменные и выполняете сценарий развертывания. Это точно так же просто, как и при использовании vSphere Client, но плюс в том, что вы можете использовать этот сценарий повторно, не проходя вручную шаги мастера клиента vSphere.
Также настроенные параметры в скрипте будут вам отличным напоминанием о том, какую конфигурацию вы использовали для виртуальных модулей.
На данный момент доступны сценарии для следующих продуктов и их версий:
Также на странице PowerShell OVF Helper размещены ссылки на OVA-модули, которые рекомендуется использовать совместно с соответствующей версией сценария.
Кстати, обратите внимание на раздел Tools на сайте автора - там много чего интересного:
Компания VMware на днях выпустила бесплатную книгу об управлении облачной инфраструктурой - Managing a VMware Cloud for Dummies. На 79 страницах этой книги доступным языком рассказывается об устройстве cпектра решений VMware Cloud, анализируются аспекты миграции онпремизной среды в облако и полезных нагрузок между облачными средами, разбираются Day-1-2-3 операции, а также подробно рассматриваются механизмы взаимодействия пользователей с облачными сервисами.
Это полноценная книга со своим ISBN:
Основные разделы документа:
Introducing the VMware Cloud
Discovering the Value of Cloud Management
Making your VMware Cloud Self-Service
Operating Your VMware Cloud
Migrating To and Between VMware Clouds
Powering Your Cloud Operating Model
(More than) Ten VMware Cloud Management Resources
Скачать книгу Managing a VMware Cloud for Dummies можно по этой ссылке.
Компания VMware объявила о первом релизе PowerCLI в этом году - на днях стала доступна для загрузки версия PowerCLI 12.5. Напомним, что о прошлой версии этого фреймворка для управления виртуальной инфраструктурой с помощью сценариев мы писали вот тут.
Давайте посмотрим, что там появилось нового:
1. Функции vCenter Server Appliance Service Management
Теперь PowerCLI поддерживает обращение к онпремизной инфраструктуре AWS, которая называется Outpost (стала доступной в конце прошлого года). Для этого есть командлет Get-VmcOutpost, который позволяет получить список доступных аутпостов для организации в VMC. Также при создании SDDC с помощью командлета New-VmcSddc есть параметр -Outpost, который позволяет создать объект в рамках аутпоста.
3. Поддержка Hot add / Remove для процессоров и памяти
Теперь есть новые параметры, в командлетах создания и настройки ВМ (Set-VM и New-VM), которые позволяют включить функции горячего добавления памяти и процессоров, а также удаления процессоров. Вот эти параметры:
-CpuHotAddEnabled (включить CPU Hot Add)
-CpuHotRemoveEnabled (включить CPU Hot Remove)
-MemoryHotAddEnabled (включить Memory Hot Add)
4. Включение шифрованной миграции vMotion
Теперь для командлетов создания и настройки ВМ (Set-VM и New-VM) есть параметр -MigrationEncryption, который позволяет включить шифрованную миграцию.
5. Обновления для Horizon 8.4
Модуль Horizon был обновлен и теперь включает в себя байндинги для Horizon 8.4 API.
Больше информации о новом релизе вы можете узнать вот тут. Скачать VMware PowerCLI 12.5 можно по этой ссылке.
Компания VMware объявила о выпуске новой версии Photon OS 4.0 rev 2. Напомним, что четвертая версия этой ОС, на базе которой построены виртуальные модули (Virtual Appliances) VMware, вышла в марте прошлого года.
Давайте посмотрим, что нового появилось в этом обновлении:
Поддержка OpenSSL 3.0 - теперь этот протокол используется по умолчанию
Новая утилита pmd-nextgen (photon management daemon), которая дает следующие возможности:
Удаленное управление системой с поддержкой мобильных устройств
Управление сервисами systemd и другими аспектами Photon OS через REST API
Использование REST API для конфигураций в реальном времени и тюнинга производительности, а также мониторинга состояния Linux-систем
Доработки движка реального времени:
Улучшения при работе с низкими задержками (low-latency), а также уменьшение джиттера (OS jitter)
Повышение стабильности работы и улучшения средств отладки
Прочие улучшения:
Доработки и багофиксы в tdnf
Поддержка GNU tarfs для ядра Linux-esx
Поддержка eBPF для ядра Linux
Улучшения установщика, такие как поддержка устройства Secondary Kickstart и пользовательских настроек монтирования устройств
Обновления пакетов:
Linux kernel 5.10.83
Glibc 2.32
Systemd 247.10
Python3 3.10.0
Openjdk : 11.0.9
Openssl : 3.0.0
Cloud-init: 21.4
Скачать Photon OS 4.0 rev 2 можно в ISO-дистрибутивах для платформ x86_64 и arm64, а также в формате OVA как виртуальный модуль для платформы VMware vSphere. Там же доступны кастомизированные образы Amazon AMI, Google GCE, Azure VHD, а также образ для Raspberry Pi.
Компания VMware объявила, что теперь ее решение VMware vRealize Automation Cloud можно дополнить продуктом SaltStack SecOps Cloud, который позволяет добавить дополнительные средства безопасности в инфраструктуру автоматизации облака. Этот компонент позволяет добавить функции соблюдения комплаенса и устранения уязвимостей в решение vRA Cloud по модели SaaS из облака.
Напомним, что ранее этот продукт был доступен только для онпремизной инфраструктуры vRealize Automation:
SecOps - это Security плюс Operations, то есть средства, которые позволяют объединить усилия команд безопасников и администраторов при конфигурации и контроле виртуальной среды. Теперь обе команды могут настраивать политики безопасности, сканировать системы на их соблюдение и активно исправлять конфигурации из единой консоли.
Многим организациям приходится соответствовать различным стандартам безопасности (ISO 27000, HIPAA, PCI, NIST и прочим), что требует выполнения тысяч различных требований и проверок. Организация Center for Internet Security (CIS) предоставляет пользователям единый фреймворк для соблюдения комплаенса в рамках различных требований и регуляций.
vRealize Automation SaltStack SecOps Cloud включает в себя базу данных сертифицированного CIS контента и требований DISA STIG (Defense Information Systems Agency Security Technical Implementation Guides), которые являются базой при конфигурации политик безопасности облачной среды.
vRealize Automation SaltStack SecOps Cloud ежедневно сканирует системы на соблюдение соответствия и предотвращает плавную "утечку" конфигураций безопасности в неправильную сторону.
Также это решение включает в себя сервисы интеграции с решением VMware Carbon Black Cloud, что позволяет дополнить средства проактивного поиска уязвимостей Black Cloud решением для исправления конфигураций и соблюдения требований регуляторов.
В дополнение к этому vRA SaltStack SecOps Cloud позволяет добавить результаты сканирования решений Tenable, Rapid7, Qualys и Kenna, чтобы ускорить настройку безопасной конфигурации среды.
Более подробно о решении vRealize Automation SaltStack SecOps Cloud можно почитать на официальном сайте.
Довольно давно мы писали о технологии Remote Direct Memory Access (RDMA) которая позволяет не использовать CPU сервера для удаленного доступа приложения к памяти другого хоста. RDMA позволяет приложению обратиться (в режиме чтение-запись) к данным памяти другого приложения на таргете, минуя CPU и операционную систему за счет использования аппаратных возможностей, которые предоставляют сетевые карты с поддержкой этой технологии - называются они Host Channel Adaptor (HCA).
Также некоторое время назад мы писали о VMware Paravirtual RDMA (PVRDMA) - технологии, поддержка которой появилась еще в VMware vSphere 6.5. С помощью нее для сетевых адаптеров PCIe с поддержкой RDMA можно обмениваться данными памяти для виртуальных машин напрямую через RDMA API, что важно для нагрузок High Performance Computing (HPC) на платформе vSphere.
Работает PVRDMA только в окружениях, где есть хосты ESXi с сетевыми картами с соответствующей поддержкой, а также где виртуальные машины подключены к распределенному коммутатору vSphere Distributed Switch (VDS). Альтернативой этому режиму использования сетевых карт является технология VMDirectPath I/O (passthrough), которая напрямую пробрасывает устройство в виртуальную машину. Это, конечно, самый оптимальный путь с точки зрения производительности, однако он не позволяет использовать многие полезные технологии VMware, такие как HA, DRS и vMotion.
Недавно компания VMware выпустила интересный документ "Paravirtual RDMA for High Performance Computing", где рассматриваются аспекты развертывания и производительности PVRDMA, а также производится тестирование этой технологии в сравнении с VMDirectPath I/O и TCP/IP:
Читать весь документ, наверное, не стоит - можно довериться методике тестирования VMware и ее подходу к оценке производительности. Тестовый стенд выглядел так:
Состав оборудования и особенности тестирования:
8 хостов ESXi 7.0 на платформе PowerEdge C6420 с Intel Xeon Gold 6148 CPU на борту (20 ядер / 40 потоков), 200GB RAM NVIDIA Mellanox ConnectX-5 Ex 100GbE NIC на канале RDMA
Карты NVIDIA Mellanox ConnectX-5 Ex NIC, соединенные через коммутатор 100GbE NVIDIA Mellanox
CentOS 7.6, 20 vCPUs, 100GB RAM, ВМ на датасторе vSAN, одна ВМ на хост ESXi
OpenMPI версии 4.1.0, использующая using openib BTL для транспорта RDMA
OpenFOAM версии 8, исполняющая тест cavityFine из руководства OpenFOAM. Этот тест исполняет симуляцию течения жидкости с заданными параметрами.
Тут можно просто взглянуть на следующие картинки, чтобы понять, что при использовании PVRDMA вы теряете не так уж и много в сравнении с VMDirectPath I/O.
Результаты теста по времени исполнения в секундах (для 2,4 и 8 хостов, соответственно):
Визуализация результатов при изменении числа узлов:
В среднем, потери производительности на PVRDMA составляют до 20%, зато вы получаете множество преимуществ, которые дает полная виртуализация без жесткой привязки к оборудованию - консолидация, HA и vMotion:
В сравнении с TCP дела тоже обстоят хорошо, результат лучше на 30-80%, в зависимости от числа узлов:
Скачать документ VMware Paravirtual RDMA for High Performance Computing можно по этой ссылке.
Мы много писали о решении VMware Cloud Disaster Recovery, которое позволяет обеспечивать катастрофоустойчивость виртуальных инфраструктур за счет резервирования онпремизных ресурсов в облаке. Службы VMware Cloud Disaster Recovery позволяют производить восстановление после сбоев по запросу (On-Demand Disaster Recovery) напрямую в облаке VMware Cloud on AWS.
VMware Cloud Disaster Recovery обеспечивает оркестрацию процесса создания реплик на хранилищах S3 Cloud, а также реализацию процесса восстановления инфраструктуры на стороне VMware Cloud on AWS с сохранением показателя RPO равного 30 минутам.
У многих пользователей такой схемы возникает вопрос - а за что они отвечают в этом процессе, за что отвечает VMware, а за что - Amazon?
Ответ можно найти вот тут, мы расскажем об этом вкратце. Итак, VMware Cloud Disaster Recovery состоит из трех компонентов:
Файловая система Scale-out Cloud File System (SCFS)
Оркестратор (Orchestrator)
Коннекторы DRaaS Connectors
VMware запустила свое DRaaS решение в октябре 2020 года и с тех пор предоставляет круглосуточную поддержку этих компонентов, включая накатывание патчей и обновлений на них.
С точки зрения безопасности и операций, ответственность распределяется по трем основным уровням - пользователь, VMware и Amazon AWS:
Пользователь отвечает за:
"Security in the Cloud":
Безопасность в облаке при развертывании и поддержке окружений VMware Cloud Disaster Recovery
Безопасность собственной виртуальной инфраструктуры и установку компонентов решения, необходимых для функционирования инфраструктуры катастрофоустойчивости. Также это включает в себя поддержку достаточной скорости соединения между площадками. Пользователь должен заботиться о протоколах шифрования, своевременном обновлении ПО, аудите систем, изменении паролей и всем прочем, что от него зависит.
VMware отвечает за:
"Security of the Cloud" - то есть за безопасность самого облака, что означает защиту систем и программного обеспечения, составляющего основу облака для служб VMware Cloud Disaster Recovery. Очевидно, что это включает в себя не только DRaaS-cервисы, но и платформенные составляющие, такие как VMware vSphere и vSAN.
Amazon отвечает за:
"Security of the Infrastructure" - физические серверы, доступ к ним в датацентрах, функционирование аппаратного обеспечения, исправность физических линий связи и соединений в рамках ЦОД.
Если говорить о разделении зон ответственности в плане конкретных операций и функциональности, то таблица в разрезе указанных трех сущностей выглядит так:
Сущность
Ответственность / Активности
Customer
Развертывание на резервном сайте в облаке объектов Software Defined Data Centers (SDDC):
Определение числа и типа хостов (i3, i3en)
Конфигурация кластера
Поддержка связанного AWS-аккаунта
Определение диапазона адресов управляющей сети
Настройка сети и безопасности SDDC:
Настройка сетевых сегментов
Конфигурация публичных IP-адресов
Настройка NAT
Настройка сетевых экранов
Защищаемый сайт:
Развертывание коннекторов
Настройка фаерволов
Настройка сетевых сегментов
Аутентификация пользователей
Регистрация серверов vCenter
SCFS:
Настройка групповых политик защиты
Конфигурация vCenter защищаемого сайта
Orchestrator:
Разработка плана восстановления (DR Plan)
Управление пользователями, ролями и аутентификацией в целом
VMware
Жизненный цикл SCFS:
Обновления ПО
Консистентность данных снапшотов
Жизненный цикл Orchestrator:
Обновления ПО
Проверка и контроль Inventory (политики и планы восстановления)
Жизненный цикл Connector:
Обновления ПО
Жизненный цикл резервного SDDC:
Апгрейд и обновление ESXi
Апгрейд и обновление vCenter Server
Апгрейд и обновление vSAN
Апгрейд и обновление NSX
AWS – Amazon Web Services
Физическая инфраструктура:
AWS Regions
AWS Availability Zones
Физическая безопасность датацентров AWS
Compute / Network / Storage:
Обслуживание стоек хостов Bare Metal (например, i3.metal и i3en.metal)
Поддержка железа стоек, компонентов питания и инфраструктуры сети
В конце лета прошлого года мы писали об интереснейшем документе "VMware vSphere Snapshots: Performance and Best Practices", который содержит весьма полезную многим администраторам информацию о производительности снапшотов, а также лучшие практики по обращению с ними. Мы, кстати, часто пишем про это (1, 2, 3), и хорошо, что теперь об этом есть и подробный документ с картинками.
В конце года VMware решила обновить этот whitepaper, добавив туда немного информации о производительности снапшотов в инфраструктуре контейнеризованных приложений Kubernetes на платформе vSphere.
Тестовая конфигурация там выглядела вот так:
Соответственно, процедура тестирования выглядела так:
Снимаем базовый уровень производительности для ВМ worker-ноды без снапшотов под нагрузкой
Создаем снапшот ВМ worker-ноды
Запускаем бенчмарк и получаем данные о производительности
Увеличиваем по одному число снапшотов и повторяем цикл тестирования
Тестировались приложения Weathervane и Redis. Результаты показали, что даже при большом количестве снапшотов производительность не падает:
На днях на сайте проекта VMware Labs обновилось средство для развертывания решения NSX Advanced Load Balancer (бывший продукт AVI Networks) - Easy Deploy for NSX Advanced Load Balancing до версии 3.0. Напомним, что об этом продукте мы впервые рассказывали вот тут. С помощью утилиты Easy Deploy можно развернуть балансировщик из интерфейса всего в несколько кликов.
Это позволит вам использовать такие функции, как multi-cloud load balancing, web application firewall и application analytics в любом облаке, без необходимости ручного развертывания и настройки продукта, которая довольно непроста.
Давайте посмотрим, что нового появилось в версии Easy Deploy for NSX ALB 3.0:
UI-фреймворк был полностью переработан, чтобы соответствовать интерфейсу NSX Advanced Load Balancer
Теперь для доступа к интерфейсу не нужна аутентификация
Был переработан API-сервер, а сами API стандартизованы
Была убрана база данных, которую заменили на систему кэширования, которая больше не сохраняет постоянных данных
Операции VMC Day 2 теперь можно выполнять за пределами объекта SDDC
Поддержка продуктов Avi версий 21.1.2, 21.1.1-2p2 и 20.1.7
Улучшен механизм управления образами, теперь можно загружать их локально через CLI
Скачать Easy Deploy for NSX Advanced Load Balancing 3.0 можно по этой ссылке.
Ну и бонус - видео о том, как работает этот продукт:
Первое в этом году обновление на сайте проекта VMware Labs - это очень полезное мобильное приложение VM News Collector. Оно представляет собой агрегатор всех новостей и обновлений о продуктах и технологиях компании VMware, который собирает все это в реальном времени.
На айфоне это выглядит так:
На андроидах - примерно так же:
VM News Collector построен на базе фидов RSS, которые добавляются из различных источников и сейчас подключены на платформе VMware Blogs.
В приложении будет информация об обновлениях, патчах, существующих проблемах и вариантах их обхода. Важные оповещения будут работать на базе пуш-уведомлений. Также заявляется, что VM News Collector будет оповещать пользователей о критических уязвимостях в различных продуктах VMware, описание которых также можно будет посмотреть в разных источниках.
Пользователь сам может выбрать, в каких категориях ему получать уведомления и видеть их в своей ленте:
Полезной возможностью продукта является функция поиска новостей и оповещений для конкретного продукта VMware.
Скачать VMware VM News Collector для iOS и Android можно по этой ссылке.
Компания VMware выпустила четвертое издание документа Global Security Insights Report 2021, в котором рассматриваются глобальные проблемы безопасности ИТ-инфраструктуры, которые были актуальны в прошлом году. В исследовании приняло участие 3 542 специалиста в должности CIO, CTO и CISO из разных организаций, которые находятся в 14 странах.
76% специалистов в области информационной безопасности рассказали о том, что число атак увеличилось, а 78% из них заявили, что это произошло по причине того, что многие сотрудники перешли на удаленный режим работы. Также 79% сказали, что атаки стали более изощренными и спланированными. Очевидно, ИТ-безопасность стала одним из главных трендов нового времени.
Растет активность Ransomware как одного из самых страшных видов атак с точки зрения экономического ущерба:
Стратегия Cloud-first Security набирает обороты:
Также использование брешей в безопасности очень плохо влияет на репутацию:
Ну и самая критичная точка по опросам, через которую может произойти вторжение - приложения:
Дорогие друзья, рекламодатели, коллеги и партнеры! От всей души и сердца поздравляю вас с наступающим Новым годом и Рождеством!
Пусть в Новом году все будет проще, приятнее и радостнее, чем в прошедшем. Все мы ждем ухода заразы, новых технологических горизонтов, личного экономического и профессионального роста - так пусть все сбудется. Мы постараемся радовать вас еще большим объемом интересного и полезного контента, позитивными новостями и всем самым актуальным из мира серверной виртуализации и контейнеризации приложений.
Компания VMware выпустила интересный документ "Intel architecture optimizes VMware SD-WAN Edge performance", в котором рассказывается о решении VMware Secure Access Service Edge (SASE) на базе аппаратных платформ Intel. Решение SASE объединяет компоненты интегрированной среды VMware, предназначенные для создания распределенной инфраструктуры безопасного и производительного доступа пользователей к приложениям и средства контроля этой активности.
Экосистема решения, описанного в документе, выглядит следующим образом:
Идея концепции SASE в том, чтобы обеспечивать защиту доступа к приложениям в географических центрах, максимально приближенных к облачной инфраструктуре, где эти приложения находятся (публичные облака и облака сервис-провайдеров). Сейчас у SASE есть более, чем 150 точек присутствия (points of presence, PoP), где физически размещено оборудование в облачных датацентрах, что позволяет построить безопасный и высокопроизводительный мост к SaaS-сервисам приложений.
Компоненты SASE включают в себя следующие решения:
Облачную технологию VMware SD-WAN, которая виртуализует WAN-сети в целях отделения программных служб от оборудования, что дает гибкость, простоту управления, производительность, безопасность и возможность быстрого масштабирования в облаках.
Компонент VMware Secure Access для удаленного доступа в рамках фреймворка zero-trust network access (ZTNA). Это новый уровень VPN-решений, который дает новые инструменты для доступа к облачным приложениям.
VMware Cloud Web Security - это интегрированное решение на базе таких техник, как Secure Web Gateway (SWG), cloud access security broker (CASB), data loss prevention (DLP), URL filtering, а также remote browser isolation (RBI), что реализовано на уровне SASE PoP для защиты прямого доступа к SaaS-приложениям и веб-сайтам.
VMware Edge Network Intelligence - это платформа для отслеживания активности подключений и сетевых потоков в рамках концепции AIOps, которая предполагает использование алгоритмов AI/ML для аналитики трафика WAN-to-branch, WiFi/LAN, а также на уровне приложений.
В документе описывается использование компонентов VMware SD-WAN Edge на базе различных платформ Intel, использующих процессоры Atom и Xeon. Требуемая конфигурация устройств SD-WAN рассматривается через призму требований приложений к пропускной способности канала, а также объема виртуализуемых сетевых служб, таких как фаерволы, системы IDS и прочее, которые работают как VNF (virtual network functions) в рамках программно-аппаратных модулей.
Дункан написал хорошую разъясняющую статью про загрузку ESXi с SD-карты и размещение раздела OSDATA на хранилище в SAN. Напомним, что мы писали о том, что VMware уходит от механизма загрузки ESXi с SD-карт ввиду их низкой надежности и неприспособленности под задачи гипервизора.
Как знают администраторы VMware vSphere, начиная с седьмой версии платформы, структура разделов ESXi теперь выглядит следующим образом:
Как мы видим, все основные разделы, не относящиеся к загрузке переехали в раздел ESX-OSDATA. Многие администраторы хотели бы хранить загрузочный раздел локально на SD-карте, а OSDATA - в сети SAN.
Действительно, тут как бы есть пункт, что при загрузке ESXi можно использовать SD-карту для Bootbank, а Managed FCoE/iSCSI LUN для OSDATA (но обратите внимание, что это Locally attached devices). Реально же FCoE, iSCSI и FC для загрузки ESXi с SAN можно использовать только тогда, когда и OSDATA, и Bootbank находятся на SAN-устройстве.
Недавно мы писали об уязвимости Log4j, затрагивающей компоненты веб-серверов Apache Software Foundation log4j Java logging, а значит присутствующей и во многих продуктах VMware. Также мы рассказывали о том, как понять, что вас сканируют на уязвимость log4j, если у вас есть VMware vRealize Network Insight.
Надо сказать, что у партнеров VMware есть такое средство, как HealthAnalyzer, которое осуществляет сбор данных с различных компонентов виртуальной среды и составляет отчет об их состоянии. Оно позволяет собрать детальную информацию о продуктах VMware Horizon, VMware vSphere и VMware NSX, которая включает в себя различные конфигурации и данные об использовании. Собранные с помощью VMware HealthAnalyzer Collector данные можно отправить партнерам VMware или в саму VMware для дальнейшего анализа.
HealthAnalyzer позволит вам обнаружить угрозы, которые описаны в статьях CVE-2021-4428, CVE-2021-45046 и CVE-2021-45105 (а это 10/10 и 7.5/10 по шкале серьезности). Однако чтобы это работало, вам нужно удалить старую версию VMware HealthAnalyzer и поставить новую с портала Partner Connect.
Чтобы удалить старую Java-версию HealthAnalyzer, нужно просто удалить ее папки и связанные файлы. Для виртуальных модулей - нужно выключить ВМ и удалить ее из инвентори.
Также если вы будете использовать предыдущую версию анализатора, то ваши регистрационные данные в форме не будут приняты:
За установкой продукта HealthAnalyzer обращайтесь к своему поставщику VMware.
Ну и бонус-видео о том, как временно обезопасить свой VMware vCenter от Log4j, пока критические фиксы еще в пути:
Компания VMware анонсировала новую версию продукта VMware HCX 4.3, предназначенного для миграции с различных онпремизных инфраструктур (на базе как vSphere, так и Hyper-V или KVM) в облако на платформе VMware vCloud. Напомним, что о возможностях версии 4.2 этого продукта мы писали вот тут.
Давайте посмотрим на новые возможности HCX 4.3:
1. Переход на PostgreSQL
Теперь HCX использует БД PostgreSQL вместо устаревших баз данных, использовавшихся ранее. Для пользователя переход произойдет незаметно, а сами данные в фоновом режиме будут перенесены на новую платформу.
2. Улучшения HCX Network Extension
Теперь для виртуальных модулей Network Extension появились функции высокой доступности (high availability). Так как сервис Network Extension является критичной частью HCX, нарушения в работе которого могут привести к серьезным проблемам с функционированием, то теперь на уровне виртуальных модулей (Virtual Appliance) есть функции HA, которые работают в режиме active/standby. В случае сбоя переключение на запасной узел происходит автоматически.
Диаграмма ниже показывает, как работают виртуальные модули NE, которые формируют пары на каждой из площадок, а во время нормальных операций трафик использует active-туннель между модулями. Другой туннель между standby-модулями также поддерживается, но трафик по нему не идет. На него происходит переключение в случае сбоя основного канала.
HA group 1 и HA group 2 имеют независимые механизмы хартбитов, чтобы мониторить состояние виртуальных модулей.
3. Улучшения OS Assisted-миграций
OS Assisted Migration (OSAM) - это режим миграции виртуальных машин из не-vSphere окружений, таких как KVM и Hyper-V, на платформу vSphere. Здесь было сделано несколько важных улучшений:
Поддержка новых гостевых ОС - теперь HCX поддерживает миграцию ВМ на базе RHEL 8.x (64-bit) и CentOS 8.x (64-bit) в окружениях KVM на vSphere. Кроме того, можно мигрировать RHEL 8.x (BIOS/GEN-1 & UEFI/GEN-2) и CentOS 8.x (BIOS/GEN-1 & UEFI/GEN-2) из виртуальных машин Hyper-V.
Совместимость HCX OSAM для vSphere и Cloud Director - теперь при миграции поддерживается связка продуктов VMware vSphere 7.0 U3 и VMware Cloud Director 7.0 U3.
4. Улучшения юзабилити
Устранен лимит на 15 символов для имен хостов ВМ на базе MS Windows при кастомизации гостевой ОС.
Возможность изменять Compute Profile в режиме OSAM. Ранее надо было явно указывать целевой датастор в профиле, теперь же HCX обнаруживает набор датасторов, которые доступны для репликации в кластер. Также происходит валидация, что Sentinel Data Receiver (SDR) имеет доступ к датастору, указанному пользователем.
Более подробно о продукте VMware HCX 4.3 можно почитать на этой странице.
Мы много пишем про растянутые кластеры VMware vSAN Stretched Clusters для онпремизной инфраструктуры VMware vSphere, но не особо затрагивали тему растянутых кластеров в публичных облаках. В частности, в инфраструктуре VMware Cloud on AWS можно создавать такие кластеры, работающие на уровне зон доступности (Availability Zones).
Облачные администраторы знают, что публичное облако AWS разделено на регионы (Regions), в рамках которых есть зоны доступности (Availability Zones, AZ), представляющие собой домены отказа (аналогичные таковым в vSAN). То есть если произойдет сбой (что довольно маловероятно), он затронет сервисы только одной зоны доступности, остальные AZ этого региона продолжат нормально функционировать.
Сама Amazon рекомендует дублировать критичные сервисы на уровне разных зон доступности, а с помощью растянутых кластеров VMware vSAN можно сделать полноценную задублированную среду на уровне AZ в рамках одного региона с компонентом Witness для защиты от ситуации Split-brain, когда будет разорвана коммуникация между зонами:
Для такой конфигурации вам потребуется создать SDDC с поддержкой Stretched Cluster, который создается на этапе настройки SDDC на платформе VMC on AWS. Надо понимать, что при развертывании SDDC можно задать тип кластера Standard или Stretched, который уже нельзя будет поменять в дальнейшем.
Пользователь задает AWS Region, тип хоста, имя SDDC и число хостов, которые он хочет развернуть. Далее администратор выбирает аккаунт AWS и настраивает VPC-подсеть, привязывая ее к логической сети для рабочих нагрузок в аккаунте. Нужно выбрать 2 подсети для обслуживания двух зон доступности. Первая устанавливается для preferred-площадки vSAN, а вторая помечается как сеть для "non-preferred" сайта.
После создания кластера, когда вы зайдете в инстанс Multi-AZ SDDC vCenter вы увидите растянутый кластер vSAN с одинаковым числом узлов на каждой из AZ и один компонент Witness, находящийся за пределами данных AZ.
Такая конфигурация работает как Active-Active, то есть вы можете помещать производственные виртуальные машины в каждую из зон, но вам нельзя будет использовать более 50% дисковой емкости для каждой из облачных площадок.
Конечно же, нужно позаботиться и о защите виртуальных машин как на уровне площадки, так и на уровне растянутого кластера. Лучше всего использовать политику хранения "Dual site mirroring (stretched cluster)" на уровне ВМ. В этом случае при сбое виртуальной машины в рамках одной зоны доступности она будет автоматически перезапущена в другой AZ с помощью механизма VMware HA.
Также администратору надо контролировать физическое размещение виртуальных машин по площадкам, а также политику Failures to tolerate (FTT):
Конечно же, не все виртуальные машины нужно реплицировать между площадками - иначе вы просто разоритесь на оплату сервисов VMConAWS. Администратор должен выставить правила site affinity rules, которые определяют, какие машины будут реплицироваться, а какие нет. Делается это с помощью движка политик storage policy-based management (SPBM) для ВМ и их VMDK-дисков:
Недавно мы писали про критическую уязвимость log4j, которая появилась в компоненте веб-сервера Apache Software Foundation log4j Java logging, а значит и во многих продуктах VMware. Атакующий, который имеет доступ к отсылке логов, может исполнять код, полученный с LDAP-серверов, когда настройка message lookup substitution включена. Это уязвимость типа "zero-day", а значит исправление ее для различных программных продуктов еще находится в процессе.
Если у вас есть средство VMware vRealize Network Insight, предназначенное для мониторинга и защиты сетевой инфраструктуры виртуальной среды на уровне приложений в онпремизном и облачном датацентре, то вы можете легко обнаружить злоумышленников, которые пытаются использовать уязвимость log4j.
Итак, вам понадобится собранный участниками краудсорсинговой кампании список IP-адресов, а также вот этот Python-скрипт от автора Martijn Smit. В VMware vRNI должен быть включен анализ потоков (flows), кроме того у вас должен быть развернут vRealize Network Insight Python SDK.
Для запуска процесса анализа сетевых подключений и потоков выполняем следующие команды:
Отработают эти команды примерно следующим образом (кликните для анимации):
Также этот скрипт можно запустить и в облачной версии vRealize Network Insight Cloud с токеном Cloud Services Portal API. Для этого надо посмотреть параметры скрипта:
# python3 vrni-log4j-flow-check.py --help
Понятное дело, что если вы найдете соединения с атакующих IP (однако, не все они могут быть вредными, так как в списке много адресов российских провайдеров), то лучше отклонить эти соединения.
Вот еще немного информации по теме, которая может оказаться вам полезна:
Компания VMware на сайте проекта Labs сделала доступной новую версию платформы виртуализации ESXi ARM Edition 1.8. Напомним, что это специальная версия гипервизора VMware, предназначенная для процессоров ARM (на их базе построена, например, архитектура Raspberry Pi, а также многие IoT-устройства). Также этот гипервизор в будущем найдет свое применение в таких платформах, как Project Monterey. О прошлой версии ESXi для ARM мы писали вот тут.
Давайте посмотрим, что нового появилось в ESXi ARM Edition 1.8:
Исправление для ACPI, что позволяет поддерживать гостевые ОС OpenBSD.
Улучшенная обработка ITS device ID width в реализации без поддержки indirect table.
Улучшенная обработка VMkernel TLB (Translation Lookaside Buffer - он представляет собой кэш для MMU).
Улучшенная обработка механизма NUMA, особенно в части сообщений об ошибках.
Скачать VMware ESXi ARM Edition 1.8 можно по этой ссылке. Напомним, что апгрейд с прошлых версий этого гипервизора не поддерживается, каждую новую версию нужно устанавливать заново.
Администраторам виртуальной инфраструктуры часто приходится менять параметры виртуальной машины, такие как CPU и память, чтобы проводить разного рода тюнинг и оптимизации. Для таких действий требуется перезагрузка виртуальной машины, что вызывает сложности в планировании.
Раньше подход был таким - к нужной дате/времени, согласованному с владельцами систем, происходила перезагрузка машин, которые за некоторое время уже поднимались в желаемой конфигурации (Desired State). Но это рождает довольно сложный административный процесс такого согласования.
Утилита VMDSC использует другой подход - виртуальные машины окажутся в Desired State при следующей перезагрузке гостевой ОС. Это позволяет не договариваться о простое ВМ в определенные периоды, а просто встраивать процесс реконфигурации процессора и памяти в жизненный цикл систем, когда им и так требуется перезагрузка (например, при накатывании обновлений).
Что нового появилось в VMDSC версии 1.0.1:
Исправлена проблема, когда сервис VMDSC мог использовать неправильный сервисный аккаунт vCenter при восстановлении соединения.
Сценарий первоначальной загрузки виртуального модуля теперь проверяет URL опционального сертификата vCenter CA в форматах DER или PEM.
Теперь в составе есть vRealize Log Insight VMDSC Content Pack (1.0), который реализует дэшборд для исторических событий VMDSC.
Появилась поддержка модуля PowerVMDSC, которая дает пользователям возможность взаимодействовать напрямую с VMDSC из PowerShell.
Скачать утилиту Virtual Machine Desired State Configuration версии 1.0.1 можно по этой ссылке.
Основная информация о возникшей ситуации с последним пакетом обновлений приведена в KB 86398. Там можно узнать, что вся линейка Update 3/3a/3b была отозвана из-за критических проблем, описанных в KB 86287 и KB 86281. На странице загрузки VMware vSphere, по-прежнему, висит красный баннер и релиз Update 2a от апреля этого года:
Среди найденных багов - и выпадение в PSOD, и проблемы апгрейда с прошлых версий, и проблемы со стабильностью vSphere HA, и многое другое, судя по заметкам в некоторых блогах:
18 ноября зачеркнутые в таблице релизы были удалены из VMware Customer Connect, а новостей по поводу сроков исправления проблем с этого времени не было. Сама VMware пишет в KB вот так:
Надо отметить, что VMware vCenter 7 Update 3 и Update 3a сейчас доступны для скачивания и использования в производственной среде.
В самом интересном положении оказались пользователи, которые уже прошли процедуру апгрейда своей инфраструктуры на Update 3. Им не рекомендуют откатывать все назад (это и не так просто, к тому же), если они не сталкиваются с критичными проблемами, такими как PSOD. Однако и сроков по доступности исправлений Update 3 тоже не дают.
RSS
